In a typical legacy data processing system, firmware provides the machine instructions that control the system when the system is being powered up or has been reset, but before an operating system (OS) is booted. That is, the firmware controls the pre-OS boot operations. Those boot operations may include a power-on self test (POST) of certain system components, as well as discovery and configuration of additional system components. The firmware may also control certain operations after the OS has been loaded, such as operations for handling certain hardware events and/or system interrupts. The firmware thus provides an interface between the hardware components of the system and software components such as the OS.
The firmware may handle boot and post-boot operations through a set of routines referred to collectively as a basic input/output system (BIOS). The firmware in a legacy data processing system may include BIOS instructions stored in system read-only memory (ROM). For purposes of this disclosure, the term “ROM” may be used in general to refer to non-volatile memory devices such as erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash ROM, flash memory, etc. The firmware may also include device drivers or other configuration code stored in ROM associated with particular components. For example, an adapter card for a video controller may include ROM with configuration code for the video controller. ROM with configuration code for an optional component of a data processing system may be referred to as an option ROM. Thus, when a legacy data processing system is started, the system obtains its firmware from local components, such as system ROM and option ROM.
In addition, a model for an interface between platform firmware and higher-level software such as operating systems was recently announced. That model is known as the Extensible Firmware Interface (EFI). Version 1.10 of the EFI Specification, dated Dec. 1, 2002, may be obtained from www.intel.com/technology/efi/main specification.htm. The EFI specification defines a set of standard interfaces and structures to be provided by low-level platform firmware, for use in loading additional firmware and booting the OS. Platform frameworks based on the EFI model, such as the Intel® Platform Innovation Framework for EFI, are expected to supplant frameworks based on the BIOS model within the next few years as the frameworks of choice for designing, building, and operating data processing systems. The Intel® Platform Innovation Framework for EFI includes low-level firmware which provides boot and runtime service calls that are available to the operating system and its loader. Since the Intel® Platform Innovation Framework for EFI comports with the EFI specification, the core services of that framework provide a standard environment for operations such as loading firmware drivers, running pre-OS applications, and booting an OS.
Under the EFI model, firmware drivers and pre-OS applications should be formatted according to the portable executable (PE) format. The PE format is the file format that Microsoft Corporation adopted as the standard format to be used for executable files to run under operating systems such as Microsoft® Windows® NT, Microsoft® Windows® XP, Microsoft® Windows® 2000, and Microsoft Windows CE®. The term “portable executable” reflects an intention to provide a common format for executable files for multiple operating systems. Linkers from vendors such as Microsoft® can be used to generate executable files in the PE format from object files in the Common Object File Format (COFF). The PE format is described in revision 6.0 of the “Microsoft Portable Executable and Common Object File Format Specification,” dated February 1999 (the “PE/COFF Specification”), available at www.microsoft.com/hwdev/download/hardware/PECOFF.doc.
A developer may build an executable image of an EFI driver for a certain native architecture, such as an IA-32 architecture or an Intel® Itanium®) architecture. Alternatively, the developer may build an executable image of the EFI driver as an EFI byte code (EBC) image. One EBC image may run on multiple platforms and architectures, including both Itanium®-based and IA-32 processor architectures, provided those platforms comport with version 1.10 (or later) of the EFI 1.10 specification. Consequently, a manufacturer may produce a device that is suitable for use with multiple different architectures by populating the device's option ROM with an EBC image of a driver for the device.
Nevertheless, under both the BIOS and EFI models of platform configuration, ROM has provided the transport for configuration code such as driver images. Unfortunately, the cost of required option ROMs adds to the cost of components such as adapter cards. It is also typically difficult or impractical to update configuration code in a data processing system. For instance, to update configuration code such as an EBC image, it may be necessary (a) to reboot to a rudimentary operating environment such as a disk operating system (DOS) environment, (b) to then flash the new code image into ROM from the DOS environment, and (c) to then reboot again, to activate the system with the new image.